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Introducing A New VRontier! 


Overview Functionality 


The tier 1 visor is the next logical step in the evolution of Head- | The tier 1 was designed and tested to fit comfortably on any 
Mounted Display (HMD) technology. After carefully research- | size head. Because the light weight integrated equipment is all 
ing human factor elements in current HMD users, the tier 1 | contained in the visor, we utilized an open design, allowing air 
achieves the highest possible performance without sacrificing | flow to vour head and face and eliminating the closed in feeling 
comfort or mobility. The tier 1 is fully integrated, easy to use, | found in most helmets. 


simple to maintain and service and competitively priced. ; : 
P , P yP To use the tier 1, simply place the unit on your head, turn a 


Because every part of the tier 1 is manufactured to the highest | knob andslide the visor in until the mask covers your eyes. The 
integrity standards, VRontier worlds provides a one year | unit is now comfortably custom fit on your head. When you 
manufacturer's warranty on all parts and labor at no extra charge. | need to view the real world, just pull the visor away from your 

face and lift up. The visor is counterweighted and balanced on 
tier 1 Technology | your head regardless of the angle. The 
: tracker island is directly centered on the 


The tier 1 visor features the VRon (Virtual Reality optical : 
top of your head and will accommo- 


non-distorting) system - one of the first optical systems ; a 

designed solely for VR applications. # POA ei date any tracker. 

bg ime irld a te (=.  ~< aoe The tier 1 easily detaches 
are ee from the head gear to quickly 

the industry. The VRon system is 

an integrated, light weight, im- 

pact resistant, low distortion opti- 

cal package. It allows you to enjoy 

a totally immersed view of a diffused, 








mourit on an arm, making it 

the first convertible HMD 

unit available! Since the 

detached visor weighs only 1.5 

: , a pounds, you can even use itas a hand-held 

tully converged Una ees eliminating the need. viewer. Keep it by your computer and use it as 

for software shifting or other complicated | a handy perspective reference as you program vour 
corrective measures. Peal tere 





Another unique feature of the tier 1 is its custom one-piece 
design. For the first time ever, the optical housing and the 
electronic compartment are one integral unit, providing supe- 
rior durabilicy, improved mounung accuracy, reducing outer 
mounting hardware and vastly improving its aesthetic appeal. 


The tier 1 has two composite NTSC video inputs for full 
stereo viewing. If vou desire, you can activate the mono mode 
by plugging in to just one input and flicking the stereo/mono 
switch. The signal is split to both screens internally so you do 
not need a “Y” cable. An LED on the visor indicates which 


The LCD screen technology used in the tier 1 is superior in color, mode you are in. 


size, weight and availability to most other VR systems. Its low power 
requirements, high performance and high resolution (479 x 234) 
places the tier 1 among the best of the stereo input HMDs. The 
viewing screens are 25% larger than most HMD LCDs, allowing 
us to proportionally reduce the optical magnification, providing a 


Fach screen can be individually tailored for brightness, color 
and tint. These controls are available under the easy to remove 
front plate, and allow custom adjustment of the viewing 
screens for your own taste and to enhance your individual 
ey Tel : sottware preferences. 

wider field of view with finer resolution. 
To complement the features of the tier 1, the unit is designed 
to be aesthetically pleasing. The high gloss fucuristic grey finish 
enhances the contours and its modern , lightweight compost 
tion makes it durable. 


PS ee ieesianaininnanenasiah eatoaanitanaaseg Sn EE I ES, 


We built the tier 1 convertible visor for you, with you in mind. Now you can sail into the new 
VRontier of tomorrow with the best technology of today! 
a a aS ea DDS SN, SNE SES Ce a EN eS a a Ne aS 








Pictures are worth a thousand words. Who 


would disagree? 


Surely a Virtual World, a world of moving 
3D pictures, is nodifferent. What one can 
see, experience, and feel is generated 
from each tiny dot that is drawn onto the 
screen from the imagination of the artist 
or programmer. 


In this issue of PCVR, we hope to make the 
images a little easier to generate onto 
the scren with a walkthrough of "The PCVR 
Renderer", "Building the PCVR Renderer", 
and "PCVR Renderer Objects", all by Joseph 
D. Gradecki. 


On the subject of drawing, our last two 
issue covers have been drawn by Bill 
Talbert of Laramie, Wyoming. We appreci- 
ate his artistic vision of PCVR themes. 
His artistic abilities are a great at- 
tribute to the magazine. 


Speaking of visual information, don't 
miss part two of John Williamson's article 
on "Visual Perception of Spatial Informa- 
tion’. 


We have a new columnist starting with this 
issue, he will explian the complexities of 
building a head mounted display as well as 
exploring some of the internals of the VR 
community. Be sure to read "VR Insider" 
by Brad Burnett. 


And last but not least, Take the VR 
Challenge! Read "My Virtual Playground" 
by Joseph D. Gradecki for the details. 


Cheers! 


Waverly R. Gradecki 
Assistant Publisher 
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What's New 





GLOBAL 3D CONTROLLER 


At ue VR'92 conference in San Jose last September, a new VR company exhibited an 
innovative new input device called the Global 3D Controller. The controller can transmit 
3D input coordinates to a host computer through a 9600 baud serial connection. In addition 
to the input coordinates, the controller's stick can be made to vibrate. This vibration 
is a simple form of tactile feedback. One use for this type of feedback could be when 
the user moves through a wall, or bumps up against it in the case of a system with static 
walls. The vibration can be programmed for low intensity (0001bh) or high intensity 
(1111b) or any value in between. | 


The design of the controller consists of a large plastic base with a joystick type 
mechanism at vone end. One top of the joystick mechanism is a blue racquetball. The 
controller allows for all of the normal joystick movements but adds the third dimension 
by putting a second mechanism up in the ball. This mechanism allows the ball to be moved 
in all directions. According to the documentation, the controller allows for linear 
motion; up, down, left, right, forward, and back. The rotational motion is roll counter 
clockwise, roll clockwise, pitch down, pitch up, yaw left, and yawright. Those interested 
in obtaining a unit can contact: 


Brad Armstrong at GLOBAL Devices 
6630 Arabian Circle 
Granite Bay, CA 95661 
Telephone 916-791=3533 
FAX 916-791-4358 


In Issue 10 of PCVR, we will present drivers for both REND386 and the PCVR Rendering 
packages. 


VRONTIER WORLDS OF STOUGHTON, INC 


fiers Wisconsin based company has just announced their new Head Mounted Display 

or Visor. A great deal more information about the Visor can be seen on the opening pages 
of this issue of PCVR. The Virtual Reality Head Mounted Display is the one piece of 
equipment that I feel is somewhat deservant of a high price. The technology behind the 
HMD is not cheap. The designer and engineer for the Visor will begin a bi-monthly column 
in PCVR starting with this issue. His main focus will be the theory begind HMDs and what 
it takes to bild one. We welcome Brad aboard. 


Developers and others are encouraged to contact the company at: 
VRontier worlds of Stoughton, Inc. 
809 E. South St. 


Stoughton, Wl 53589 
PHONE/FAX: 608-873-8523 
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Letters To 


The Editor 





As always, we appreciate 
your comments. If you have 
something you would like to 
tell us, you can write us at: 


PCVR 

Attn: Editor 

1706 Sherman Hill Rd, Unit A 
Laramie, Wyoming 82070 


Errors! 


An error appeared in issue 
five of PCVR. The following 
line should be added to the 
skeleton.c program: 


int head device = 0; 
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THE 
PCVR 
RENDERER 


Joseph D. Gradecki 


A new 
rendering 
system for 
the PC. The 
name of the 
new 
render is the 
PCVR 
Renderer 
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T he majority of the past 
issues of PCVR have dealt 
with the hardware side of 
Virtual Reality. We have 
covered interfacing differ- 
ent products to the PC and 
creating new pieces of equip- 
ment for our own use. Now, 
we need to focus on the 
software which drives the 
hardware. 


We accomplish this by docu- 
menting the creation of a new 
rendering system for the PC. 
The name of this new render 
is the PCVR Renderer. In 
this issue of PCVR, we present 
three articles which docu- 
ment the basic renderer. 
After we are all through 
designing and building the 
renderer, we will have a 
system that provides’ the 
following features: 


* Complete integration with 
other PC rendering systems 


* True Stereoscopic render- 
ing 


* Multiple light sources and 
appropriate shading 


* Use of Protected Mode on 
the 386 and above. 


* Driver code for all PCVR 
Projects in the past and 
future 


* Virtual memory and Com- 
pression for objects’ and 
worlds 


* Off and Online Application 
Editors 






* and many more 





Initialize 
Renderer 


While we cannot 
accomplish all 
of this ina 


Read Draw 
———) | ———» 


Single issue, we will pro- 
vide you with a complete 
system on the enclosed disk. 
The second article on the 
PCVR Renderer details this 
code. 


I hope you enjoy using this 
renderer. If there are any 
features that you want me to 
add or want to add yourself, 
please contact me so that I 
can distribute a single ver- 
sion that benefits all of our 
readers and those in the VR 
community. 


THEORY OF OPERATION 


To the best of my knowledge, 
no know has ever sat down and 
talked about the theory be- 
hind a Virtual Reality ren- 
derer. All of the computer 
graphic books go into 
excrutiating detail about 
this and that algorithm but 
without an extensive math- 
ematical background, most of 
the text is useless. 


The actual theory behind a 
renderer is pretty straight- 
forward. Ablock diagram for 
a very simple renderer is 
given in Figure 1. 


Each of these parts can be 
broken down into’ smaller 
pieces. A new block diagram 
for the next level would be 
like Figure 2. 


AS you see, this is a much 
more detailed sequence for 
the renderer. The next and 
last level of the renderer 







Figure 1 





st a 


Initialize 
Renderer 


Read 
Object 
Characteristics 


that we show in a block 
diagram is quite large. The 
new diagram is_ shown in 
Figure 3. 


In order to show the theory 
behind a renderer, we will 
examine each of the parts in 
figure 3 and how they relate 
to one another. 


CREATE USER VIEWPOINT 


The viewpoint is the techni- 
cal jargon for the position 
of the users eye. In the 

PCVR Renderer, the viewpoint 
can be positioned anywhere 
in the three dimensional 
right-handed coordinate sys- 
tem. The right-handed coor- 
dinate system means the x 
axis is horizontal to the 
computer screen with posi- 
tive x increasing to the 
right, and the y axis is 
vertical to the computer 
screen with positive y in- 
creasing up, and the z axis 
is perpendicular to the com- 
puter screen with positive z 
increasing out of the screen. 
Therefore, a typical view- 
point may be at position 
(0,0,300). The origin of our 
coordinate system would be 
in the center of the screen 
and into the screen 300 
units. 


Initialize 
Object 
Structure 


Figure 2 


Most all the mathematical 
calculations for three di- 
mensional graphics is per- 
formed using matrices. For 
this reason, the viewpoint 
is put into a matrix for 
further calculations. If we 
assume that the variable X is 
the value for the x position 
of the viewpoint, and so on 
for Y and Z, we produce the 
following matrix. 


100 xX 
010 Y 
0012 
0001 


As will be seen in the next 
article, the viewpoint can 
be rotated about each of the 
axes. These rotations are 
stored in the same matrix. 


INITIALIZE OBJECT LIST 


The PCVR Renderer display s 
any number of objects; lim- 
ited only by available memory. 
All objects are stored ona 
linked list by their center 
Z coordinate. Thus objects 
farther away will be first in 
the list. This object linked 
list has both beginning and 
ending pointers which are 
called: OBJECTLISTSTART and 
OBJECTLISTEND. During ini- 
tiakization, the start 





pointer is assigned the value 
of the end pointer and the 
end pointer is assigned the 
value of the start pointer. 


SET GRAPHICS MODE 


This step takes us from 
normal text mode into the 
desired graphics mode for 
the rendering. Many people 
have asked about the low 
resolution in the PC render- 
ing packages. The most 
common mode used is 320 x 200 
x- 256. There are several 
reasons for this choice. The 
first is that most VGA-TO- 
NTSC converters can handle 
this mode with little diffi- 
culty. The second is that 
there are at least four pages 
of display memory available 
for this mode. It is true 
that for flickerless anima- 
tion only two pages are 
necessary but when one con- 
Siders stereo viewing, the 
number of buffers doubles 
because the separate images 
are created. Thus we need a 
page for each image to dis- 
play and a page for each new 
image, for.a total of four 


pages. 
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INITIALIZE PALETTE 


In order for there to be 
color in the rendering pro- 
cess, the program-must have 


a scheme for choosing col- 


ors. By manually loading a 
palette, the programmer can 
setup any coloring scheme 
necessary. 


The PCVR Renderer provides 
the feature of lights. There 
is an ambient light source 
which provides an overall 
lighting to the scene. In 
addition, a programmer can 
define any number of light 
sources and directions. The 
direction of the light is 
defined as a three dimen- 
Sional coordinate such as 
(0,0,-1). This would indi- 
cate that the light source is 
coming from the negative Z 








Do Do ; 
3D | shading 
Clipping vi : 
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direction. The intensity of 
the light is defined using 
the standard RGB model. Cal- 
culating the degree of light 
received by an object from 
each of the light sources is 
fairly simple and is covered 
later in the rendering se- 
quence. 


SET BACKGROUND COLOR 


The system allows for the 
screen to be sectioned into 
two different colors. The 
variable SKY is the upper 
half of the screen color and 
GROUND is the bottom half of 
the screen color. These two 
variables can have any value 
from O to 255, where O is 
black and 255 is white. To 
further control the back- 
ground coloring, a variable 
called DRAW HORIZON is used 


Read 
Object 
Characteristics 





Figure 3 


to determine if the SKY and 
GROUND variables are used or 
not. If DRAW _HORIZION is 0, 
the entire screen is painted 
black otherwise it is painted 
using the variables. 


SHOW FIRST PAGE 


The renderer begins by show- 
ing a black screen. This 
step selects the proper page. 


INITIALIZE OBJECT STRUCTURE 


This step as well as the next 
two are performed for each of 
the objects that the render 
is instructed to use. . The 
object structure holds in- 
formation such as the number 
of vertices, the actual ver- 
tices themselves, the number 
of polygons or faces that 
make up these objects and 





Hidden 


Surface 
Removal 





Get 
Draw show | 
[| input] 
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other information that will 
be discussed in the third 
article. As with the view- 
point, each object has a 
transformation matrix asso- 
Ciated with it. This trans- 
formation matrix is used to 
hold the rotations, transla- 
tions, and scalings per- 
formed on the object. 


READ OBJECT FORMAT 


The PCVR Renderer can read 
three types of objects di- 
rectly. These are PLG, OFF 
and the PCVR Renderer for- 
mat. Depending on the object 
type, different routines are 
used to input the object 
characteristics. 


READ OBJECT CHARACTERIS- 
TICS 


An object consists of some 
number of vertices and some 
number of polygon descrip- 
tions. All of this informa- 
tion is necessary for the 
proper creation of the ob- 
ject. 


This step reads all of the 
information from the object 
file and places it in the 
initialized object  struc- 
ture. The objects are con- 
sidered to be in World Coor- 
dinates. World Coordinates 
refer to the actual three 
dimensional coordinate sys- 
tem used by the application. 
Objects are typically de- 
Signed in world coordinates 
and transfered to other co- 
ordinates by the renderer. 


TRANSFORM OBJECTS TO VIEW 
SPACE 


We now begin the steps that 
the renderer will perform in 
a loop. As the user inter- 
acts with the application 
program, the renderer has to 
continually display the ob- 
jects. The first step inthe 


actual renderering process 
is to convert the objects to 
view space coordinates. This 
is accomplished ina two step 
process. 


The first step in converting 
object to view coordinates 
is to apply the objects 
transformation matrix to each 
of its coordinates. Previ- 
ously, we defined the object 
in specific world coordi- 
nates. If the user were to 
instruct the program to move 
the object to a different 
location, the vertices of 
the object would change by 
the amount specified in the 
transmformation matrix. 


The second step is to apply 
the viewpoint transforma- 
tion matrix to the new ver- 
tices. This step brings that 
object into a relationship 
with the viewpoint. 


In the PCVR Render, the 
viewpoint matrix and the 
objects transformation ma- 
trix called the XformToWorld 
matrix are multiplied to- 
gether to produces the ob- 
jects XformToView transfor- 
mation matrix. All of the 
vertices are transformed 
using this matrix to produce 
a list of XformedVertices. 


DO PERSPECTIVE PROJECTION 


The perspective projection 
step 1S necessary to. give 
depth to our world. The 
basic idea is to divide each 
of the x and y coordinates by 
the z coordinate. Thus the 
further away an object is, 
the smaller it will appear. 
For more information on per- 
spective projection, see the 
GRAPHICS column in PCVR Is- 
sue 2. 


TRANSFORM TO SCREEN COOR- 
DINATES 


After the object's vertices 
have been projected to view 
space, it is time to trans- 
form the vertices to actual 
screen coordinates. This is 
a simple procedure of ad- 
justing the perspective gen- 
erated vertices for error 
and adding half the screen 
width to the x coordinates 
and half the screen height to 
the y coordinates. 


SELECT NEW PAGE 


To provide smooth transition 
from one image to another, 
separate graphic pages are 
used for viewing and draw- 
ing. Since we are drawing, 
we must select a new page to 
draw on. 


DRAW BACKGROUND SCENE 


Before the objects are drawn, 
the background scene is pro- 
duced. If the DRAW_HORIZION 
variable is set, the top half 
of the screen is drawn the 
color inthe variable SKY and 
the bottom half of the screen 
is drawn the color in the 
GROUND variable. Le 
DRAW HORIZON is zero, the 
background is drawn as black. 


SORT OBJECT BY Z COORD 


To help facilitate depth 
perception, we want to do our 
best to draw objects that 
appear closer to us in front 
of objects that appear far- 
ther behind. This technique 
gives the user an additional 
depth cue. The objects in 
the object linked list are 
scanned to determine if any 
of the objects are out of 
place the 
tCfransformat Lon. 


Since previous 
A Sort, is 
performed on the Z coordi- 
nate of the center of the 


object. 
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DO HIDDEN SURFACE REMOVAL 


Hidden surface removal is a 
technique that decreases ren- 
dering time for objects. For 
example, take a cube seen 
from one side of the cube, 
all five other sides cannot 
be seen. Therefore, there is 
no need to draw the other 
sides. 


The PCVR renderer performs 
hidden surface removal by 
first calculating the normal 
to the current polygon con- 
cerned about. If the normal 
is visible by the viewpoint, 
(has a positive Z direc- 
tion), then the polygon should 
be drawn. If the normal 
direction is negative, (away 
from the viewer), then the 
polygon is discarded. 


DO 3D CLIPPING 


Once a polygon has been 
accepted for drawing, it 
must go through the next four 
step. First, the vertices 
are clipped to the screen 
coordinates, the near clip- 
ping plane, and far clipping 
plane. This accomplishes 
several things. The first is 
all polygons that are com- 
pletely outside the bound- 
aries of the users screen 

are not drawn. All polygons 
that appear very far away 
from the viewer are not 
drawn. All polygons that are 
behind the user are not 
Grawn. All other polygons 
are either entirely inside 
the viewport of the user or 
are partially inside. Those 
partially inside the viewport 
are clipped at the bound- 
aries. 


DO SHADING OR TEXTURE 


After a polygon has been 
clipped, it needs to be 
colored or textured. The 
PCVR Renderer has the abil- 


10 Issue #8 March/April, 1993 PCVR 


ity to texture map polygons, 
however this feature will 
not be activated until a 
later date once it has been 
fully tested. Shading is 
performed using the ambient 
and spot light sources ini- 
tialized by the programmer. 
Since the ambient light source 
is an overall light source 
such as the sun, the polygons 
RGB variables are given the 
full intensity of the ambi- 
ent light. Thus if the 
intensity of the ambient 
laght i was (126, “120,;- 1.0) 
then the color of the polygon 
would be white since there 
can be no more than full 
percent of all red, green, 
and blue colors. 


The system continues by look- 
ing at each of the light 
sources. The amount of 
intensity received by a poly- 
gon from a particluar light 
source is determined by the 
cosine of the angle between 
the light direction and the 
normal of the polygon. It 
the light is shining from 
behind the polygon, it should 
not receive any light from 
that spot light. However, if 
the polygon is directly in 
front of the light, it re- 
ceives full intensity. The 
polygons RGB variables are 
summed for the ambient light 
and all spot lights that are 
currently on. 


SCAN CONVERT OBJECT 


The next step is to determine 
the pixels that make up the 
actual polygon. This is done 
using a technique called 
scan-conversion. We will 
discus the details of scan 
conversion in a later GRAPH- 
ICS column. The basic idea 
is to find the end points of 
all the horizontal lines 
that make up an object. All 
of these endpoints are stored 





in a list to be drawn. 


DRAW OBJECT 


The last step in the drawing 
process is to draw the line. 
This routine is given a list 
of all the horizontal lines 
to draw. Each line is drawn 
in succession. 


SHOW PAGE 


Once all of the objects have 
been drawn, the current draw 
page becomes the view page. 


GET USER INPUT 


Somewhere in this rendering 
process, input from the user 
must be obtained. This could 
be movement or selection. If 
the user is given the ability 
to pan their viewpoint, then 
the system has to change the 
viewpoint transformation 
matrix. The user may also be 
able to move objects thus 
requiring the program to 
adjust the objects transfor- 
mation matrix. 


GET EXTERNAL DEVICE INPUT 


PCVR magazine has documented 
the construction of several 
external devices for the PC 
and Virtual Reality. Our 
renderer must have the abil- 
ity to access these devices 
and interpret their rela- 
tionship to the viewer and 
the objects in the system. 


DO EXTERNAL DEVICE OUTPUT 


This step is mainly for 
shutter glasses or head 
mounted displays. Each of 
these devices require a spe- 
cific technique to provide 
the correct operating condi- 
Cian. 


That is one complete render- 
ing sequence. There are many 
different techniques’ that 
can be used in place of some 


of our steps. Scan conver- 
sion is just one way to fill 
a polygon. 


FUTURE 


The purpose begind the PCVR 
Renderer, besides render- 
ing, is to teach. I am not 
trying to compete with REND386 
or any other PC rendering 
package. I will, in future 
issues of PCVR, present full 
articles on enhancements as 
well as a bi-monthly column 
which will talk about all 
aspects of the PCVR Render in 
complete detail. 


I want to create a system 
that can be used and modular 
enough so that we can inter- 
change algorithms for spe- 
cific parts. For instance, 
scan converting may not be 
the fastest way to fill our 
polygons. So ina future 
column, we will interchange 
other polygon fill algo- 
rithms and see which is the 
fastest. 


It should be noted that we 
are creating this renderer 
from the original X-Sharp 
source code from Dr. Dobbs 

magazine. All appropriate 
acknowledgements should be 
given to the original au- 
thor. However, the code has 
been extensively changed and 
will continue to be changed 
in the future. So for an 
overview of the ‘ original 
code, read the Dr. Dobbs 

column. For the complete 


system, stay tuned to PCVR. 
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BUILDING 
THE 
PCVR 
RENDERER 


Joseph D. Gradecki 


We are now 
ready to look 
ai a simple 
skeleton 
program and 
the procedure 
for using the 
renderering 
package 
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Tne previous article dis- 
cussed the main renderering 
loop for the PCVR Renderer. 
We are now ready to look at 
a simple skeleton program 
and the procedure for using 
the renderering package. 


SKELETON PROGRAM 


Figure 1 (p.15) shows a 
typical skeleton program for 
the PCVR Renderer. The 
program provides the follow- 
ing features: 


* A single RED light source 
coming from the behind the 
viewer 

* A BLUE ambient light source 
* Reads an object file called 
test.obt 

* Allows the object to be 
manipulated using the key- 
board 


The skeleton program is com- 
piled using the object files 
contained on the PCVR Issue 
#8 disk and a makefile pro- 
vided. At this point in the 
development of the system, 
it only compiles under the 
small model in Borland C++ or 
Turbo C compiler. This will 
be changed in the near fu- 
ture. Use the Project facil- 
ity of Borland or Turbo C to 
open the project file. To 
access the skeleton program, 
move the cursor bar in the 
Project window to the 
pevrskel.c description and 
press return. To compile and 
link the program, press F9. 
The program can be directly 
executed by pressing CNTRL- 
ro. 


Lets begin by taking a look 
at the skeleton program. 


INCLUDE FILES 


All of the necessary proto 


types for the PCVR Renderer 
functions as well as all 
major structures are located 
in the include § file 


pevrrend.h. The system 
will not compile without 
this include file. The 


proper syntax is: #include 
'pevrrend.h'. | 


GLOBAL VARIABLES 


The PCVR Renderer consists 
of fifteen to twenty sepa- 
rated compiled objects files. 
Many of these files access 
the same variables. The main 
program, our skeleton file 
in this case, needs access to 
several variables in the 
other programs. We use 
global variables to accom- 
plish this task. The first 
set of variables control the 
background scene colors. They 
are defined as: extern int 
sky, ground, screencolor, 
draw horizon;. SKY, GROUND, 
and DRAW HORIZON were all 
described in the previous 
article. SCREENCOLOR de- 
fines the background color 
if DRAW HORIZON is set to 0. 


One advanced feature of the 
PCVR Renderer is the ability 
to create stereoscopic im- 
ages. A single global vari- 
able, int STEREO = 0;, con- 
trols whether the system 
creates monoscopic or ste- 
reoscopic images. If STEREO 
is set to 0, monoscopic 
images are created. i leo 
STEREO is set to l, stereo- 
scopic images are created. 


The last three global vari- 
ables are used to calculate 
the total number of frames 
per second that are gener- 
ated by the system. They are 
defined as struct time start, 
finish; and longtotal redraw 





= 0;. The program displays 
the frames per second value 
at the end of the program. 
This is not a necessary part 
of the system and can be 
eliminated. 


FINAL FUNCTION 


In order to guarantee that 
the system is returned to a 
stable state upon any er- 
rors, a Finalizing function 
is setup so that if the 
system exits per an error, 
the screen will be returned 
to normal. The function can 
be called any name but should 
be included in all programs. 
Our function in the skeleton 
program is called WRAPUP and 
has two tasks. 


The first is to return the 
graphics card to its origi- 
nal state. This is done with 


the code: 
regset.x.ax = 0x0003; 
int86(0x10, &regset, 


é&regset); 


The second tasks is to gen- 
erate the frames per second 
(FPS) value. The system 
grabs the current time of the 
system and calculates the 
total number of seconds that 
the system has been execut- 
ing. Using the total number 
of redraws that took place, 
the system calculates the 
correct FPS value. 


Example: 


secsl = start.ti_hour*3600 + 
start.ti_ min * 60 oh 
start.ti_ sec; 


secs2 = finish.ti_ hour*3600 
+ Finish.ti min * 60 +4 
finish.ti_ sec; 


printf ( "\n\nFrame/sec = 
tld", total redraw/(secs2- 
secsl) ); 


MAIN FUNCTION 

The main function handles 
all of the main steps in the 
renderer. 


VARIABLES 


The variables in the skel- 
eton program are the bare 
bones necessary to read a 
Single object and create one 
light source. The first 
variable defined as, int 
Done = 0;, is used inthe user 
loop described later in the 
article. The second vari- 
able is used to handle a 
Single object and is defined 
as PObject *object;. The 
third variable handles a 
Single light source and is 
defined as int light one;. 


FINAL SET 


The FINAL FUNCTION defined 
above has to be initialized 
with the system. The func- 
tion call atexit(wrapup); 
performs the initialization. 


VIEWPOINT 


All programs must have at 
least one viewpoint. A 
viewpoint is defined using 
the fin ohoen 
CREATE VIEWPOINT. The fol- 
lowing code illustrates the 
use of the function: 
ij dootut @ 108 WoL oo mr = 
C-r.6 act @,oVvib® w pwocdjat 
(0.0,0.0,300.0,0,0,0) )==NULL) 
{ printf ("View cre- 
ation failed.\n"); exit(1); 


} 


The parameters to the func- 
tion arés x translation, Y 
translation, Z translation, 
Pan, Tilt, and Roll. If the 
function is successful, a 
pointer to a viewpoint struc- 
ture is returned otherwise 
NULL is returned. 


INITIALIZATIONS 


As described in the previous 
article, several internal 
structures must be initial- 


ized. The following three 
statements initialize the 
objectlist, graphics mode 


and palette. 


InitializeObjectList(); 
SetGraphicsMode(); 
InitializePalette(); 


READ OBJECT 


Reading objects into the 
system is easy. Acalltothe 
function INITIALIZE OBJECT 
is all that it takes. The 
following 1s an example. 


object=initialize object 
("cube.obt",0,0,-100); 
new attrib(object); 


Recall that the object pointer 
OBJECT was defined earlier 
in the main function. This 
variable is set equal to the 
object pointer fromthe func- 
tion call. The first param- 
eter in the call is the exact 
filename of the object, the 
remaining three parameters 
are the translation values 
in X, Y, Z order. When this 
function is called, it as- 
sumes that the object is not 
moveable. It simply reads 
the object file and places 
the object at the transla- 
tion position. The next 
statement converts the ob- 
ject to a moveable one. The 
function NEW ATTRIB attaches 
an ATTRIB structure to the 
object allowing it to be 
manipulated. The only pa- 
rameter to the function is an 
object pointer. 


SETUP LIGHTS 


The next step is to set up the 
lighting in the world. We 
begin by initializing the 
lights themselves with the 
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statement 
initialize lights();. 


This sets up all of the 
internal data structures 
necessary for lighting. We 
can now define lights using 
the function call ADD LIGHT. 
The parameters to this func- 
tion are the current view- 
point, the direction that 
the light should illuminate, 
and the Red, Green, Blue 
intensity of the color. The 
following code defines a 
light source of intensity 
100% RED and shining in the 
negative Z direction or into 
the screen. 


light one = addlight /( 
view one, 0.0, 0.0, -1.0, 
1.0, 0.0,0.0 ); 


Lights can be turned on and 
off using the functions 
TURN LIGHT ON and 
TURN LIGHT OFF. The param- 
eter to the function is a 
pointer to the light source. 
turn_light_on ( light_one ); 


We can also set up an ambient 
light source using the func- 
tion SETAMBIENTINTENSITY. 
This functions takes as its 
parameters the RGB intensity 
of the light. The following 
code illustrates this func- 
tion: 


SetAmbientIntensity ( 0.1, 
0.1, Osl)}3 


The ambient light source is 
turned on and off with the 
functions TurnAmbientOn() and 
TurnAmbientOff(). 


BACKGROUND STUFF 


We now set the colors of the 
background. To draw the 
horizon, set DRAW HORIZON 
equal to one. Then the 
variables SKY and GROUND are 
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given their colors. We use 
the function RGBToColorIndex 
to set the variable to the 
appropriate color value. 
Since we only have 256 color, 
we have to convert the RGB 
color to the appropriate VGA 
color. 


draw_horizon = 1; 

sky = RGBToColorIndex(0.0, 
0.0, 1.0); 

ground = RGBToColorIndex ( 
0.0, 1.0, 0.0 ); 


SET STARTING PAGE 


We are going to start dis- 
playing the first graphics 
page. The following code 
sets that page: 
ShowPage (PageStartOffsets 
[DisplayedPage = 0]); 


GET STARTING TIME 


For our frames per second 
calculation, we need to get 
the time before we start any 
renderering. 


gettime(&start); 


SCREEN REDRAW 


Inside of the main user loop, 
we have to call the routine 
SCREEN REDRAW to determine 
whether or not the screen 
needs to be redrawn. The 
parameter for the function 
is a pointer to the current 
viewpoint. Notice that the 
screen can be redrawn using 
any viewpoint. 


screen redraw(view one); 


USER LOOF 


The user loop allows the user 
to interact with the soft- 
ware. In the skeleton pro- 
gram, the only defined key- 
board activity is the q key 
for quitting the program. 


Example: 


while (kbhit()) 


{ 
switch(c = getch() ) 
{ 
case 'q': Done = 1; break; 
default: break; 
hy 


KILL EVERYTHING 


When the viewpoint and lights 
were initialized and set up, 
memory from the computers 
heap was allocated. The 
following function releases 
that memory. 


destroy viewpoint (view one); 
remove lights(); | 


TRIGGER FINAL FUNCTION 


The last statement in the 
skeleton program triggers 
the FINAL function. 


exit(l); 


CONCLUSION 


The skeleton program is just 
that, a skeleton. It should 
be used to develop further 
programs. As we progress 
with the development of the 
PCVR Renderer program, we 
will document further fea- 
tures. 


#include <stdio.h> 
#include <stdlib.h> 
#include <conio.h> 
#include <dos.h> 
#include <math.h> al 
#include pcvrrend.hY 


int STEREO = 


extern int ag? ground, screencolor, draw horizon; 
7 


struct time start, finish; 
long total redraw = 0; 


void wrapup() 
{ 


} 


union REGS regset; 

long secsl, secs2; 

gettime ( &finish ); 

regset.x.ax = 0x0003; /* AL = 3 selects 80x25 text mode */ 
int86(0x10, &regset, &regset) ; 


start.ti_hour*3600 + start.ti min * 60 + start.ti sec; 
finish.ti_ hour*3600 + finish.ti min * 60 + finish-ti_ sec; 


secsl 
secs2 


printf ( "\n\nFrame/sec = %ld", total redraw/(secs2-secsl) ); 


void main() 


int Done = 0; 
PObject *object; 
int light one; 


atexit (wrapup); 


if((view_one = create viewpoint (0.0,0. 
{ printf ( "View création failed.\n") 


InitializeObjectList(); 
ae ak cr pero A 
InitializePalette(); 


object = initialize object("cube.obt", 35,0,-100); 
new attrib(object) ;— 


initialize pee eg Pa 
light one = add light ( view one, 0.0, Ure lee, TO O50 73 
turn _Tight_on (“light one );~— 


SsetAmbientIntensity ( 0.5, 0.5, 0.5 ); 
TurnAmbientOff() ; 


draw horizon = 0; 


Sky = RGBToColorIndex(0.0, 0.0, 1 0) 
g 


ground = RGBToColorIndex( 0.0, 1.0, 0.0 i 


/* Start off ee page 0 */ 
ShowPage(PageStartOffsets[DisplayedPage = O})}3 


ettime(&start) ; 
O 


screen redraw(); 
while (kbhit() ) 
{ 


ee = getch()) 


case 'q': Done = 1; break; 
default: break; 
} 
} while (!Done); 
destroy viewpoint ( view one 1; 
remove Tights(); - 
mein Figure 1 
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lip oer we have a render- 
ing system, we need the 
ability to add objects to be 
rendered. The PCVR Renderer 
uses an object file with the 
extension .OBT. This object 
format differs from most in 
that it includes a normal 
vector for each of the poly- 
gons and uses fixed point 
numbers. Therefore, to keep 
compatibility with other 
object formats, the PCVR 
Renderer has two specialized 
programs called, LOADOFF, 
and LOADPLG which convert 
OFF and PLG objects to the 
OBT format. 


We recommend, as the design- 
ers of REND386 do, designing 
your objects in the OFF 
format because of its wide 
spread use. We will look at 
each of the OFF and PLG 
formats and discuss the dif- 
ferent manipulation tools 
available in the PCVR 
Renderers library. 


PLG FORMAT 


Readers of PCVR are familiar 
with the rendering package 
REND386. This PC based 


cube 8 6 
00 0 

a0 0 0 
10 10 O 
Oo 19 0 

0 0 -10 
10 O -10 
10 10 -10 
0 10 -10 
Oxl1ftt 
Oxlift 
Oxllff 
Oxi et ft 
Oxi Lit 
UxiLitt 


Figure 1 





rendering package uses an 
internal object format called 
PLG. This format is a 
Simplistic view of the OFF 
format. Figure 1 shows a PLG 
file for a cube. 


Each PLG file can contain any 
number of different objects. 
Each of the objects begin 
with a description line. The 
line includes the name of the 
object, the total number of 
vertices, and the total num- 
ber of polygons in the ob- 
ject. For the cube object, 
the name of the object is 
cube, there are eight ver- 
tices and six polygons. 


After the description line, 
the vertices are listed in 0 
through n-1 order. Notice 
that there are no commas 
between the individual com- 
ponents of the vertices. 
After the vertices come the 
polygon definitions. 


Each polygon definition 
starts with the color of the 
polygon. For the LOADPLG 
program to operate correctly, 
this value should be 0-15 or 
OxXLOFP..=— ,-Qx2FFF ; Further 
improvements to the LOADPLG 
program will remove these 
restrictions. The color 
value is followed by a value 
indicating the total number 
of vertices that make up this 
polygon. This is followed by 
a list of index numbers into 
the list of vertices de- 
scribed earlier. The verti- 
ces must be listed in clock- 
wise order when looking at 
the polygon. 


To convert PLG object files 
to the OBT format, we use the 
LOADPLG program. Figure 2 
shows a typical session us- 
ing the program. 


loadplg walll 


Successful opening of walll.obt 
Sucessful opening of walll.plg for conversion 


Name of object is wall 


A total of 4 vertices and 2 polygons 


Reading vertices 


Vertices read successfully 


Start of reals 4 


Figure 2 


OFF FORMAT 


We recommend building ob- 
jects using the OFF format. 
This format allows for the 
creation of objects that can 
be used in a variety of other 
software packages and is 
freely transferable in pub- 
lic domain. The format is 
defined by the creation of 
two files called the geom- 


etry (.geom) file and the 
header file (.aoff). The 
header file includes’ the 


following information: 


name 
description 
author 
copyright 
type 
Propertylist 


The information in the prop- 
erty list is standard except 
for the color of the object 
which is described in the 
common red, green, blue for- 
mat where 1.0 is full color. 


The geometry file is where 
the actual polygon is de- 
fined. It is essentially the 
same as the .PLG file de- 
scribed above except the 
color information is in the 
header file. Figure 3 shows 
an example of a geometry file 
for a simple cube. 

been 


Once an object has 





defined in the OFF format, it 
is converted to the PCVR 
Renderer using a conversion 
program called LOADOFF.EXE. 
Figure 4 shows the conver- 
sion of an OFF object file 
called test. 


& & & SF F&F POON NNN OC O OO 
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OBT FORMAT 


For completeness, we need to 
describe the OBT format of 
the PCVR Renderer object 
files. An example of an OBT 
object file for a cube is 
shown in figure 5. 


Each object file has four 
parts. The first part de- 
scribes the object in the 
file. In our case, we have 
named the object a cube and 
have given the author and 


copyright information. This 
part of the object is not 
read by the renderer so it is 
set off by the # symbol. 
Whenever the renderer en- 
counters the # symbol, it 
ignores it and anything to 
the right. 


One part of this section of 
the object file is very 
critical to the object. This 
line begins with the word 
name. 


name cube 14 6 8 


This line tells the renderer 
about the object it is going 
to create. The word after 
name is recorded by the 
renderer as the official 
name of this object. The 
first number is the total 
number of vertices that the 
object file contains. The 
second number is the number 
of polygons that make up this 
object. The third number is 
the total number of real 
vertices in the file. 


The second and third parts of 
an object are made up of two 
types of vertices. The first 
are called real vertices and 
are listed first inthe file. 
The second type of vertex is 
anormal vertex. This vertex 
is the unit normal vector for 
a particular polygon. 


The first vertices listed 
are the real vertices. These 
vertices must be in fixedpoint 
notation. 


The real vertices for our 
cube are: 


O°o 0 

O 655360 O 

655360 655360 O 
655360 0 O 

655360 O -655360 
655360 655360 -655360 
O 655360 -655360 
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loadoff cube 


Successful opening of cube.obt 
Sucessful opening of cube.aof for conversion 


The 
The 
The 


description is a cube 
author is joe 

The copyright is none 

The type is polygon 
Vertex order is clockwise 


Color type is default and red = 


1.000000, blue = 1.000000 


name of this object is cube 


1.000000, green = 


| Successul opening of cube.geo for conversion 


Vertices = 8, points = 6 


Minimum value is -2.000000 


Figure 4 


U0 655360 


The next vertices are the 
normal vectors: 


0 0 65536 

720896 O O 
651293 0 =720626 
-65210 0 =661880 
O 720896 0 

0 -65210 -661880 


The fourth part of the object 
is the polygon descriptions. 


255 
4 8 
£99 


255 255 diffuse| ambient 
G1. 2.3 

255 255 diffuse| ambient 
493254 

255 255 255 diffuse| ambient 
4104567 

255 250 295 diffuse/| ambient 
i 11 7.6 1-2 

255 255 255 diffuse|ambient 
4°12 16'S 2 

295 255 255 diffuse|ambient 
4°13 70 3 4 


The polygon descriptions 
contain a great deal of 
information. The first three 
numbers are the color of the 
polygon in red, green, and 
blue order. A value of 255 
indicates a full saturation 
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of the indicated color, 0 
indicates no color. The next 
field indicates the lighting 
for this polygon. The valid 
values are: 


diffuse 
ambient 
diffuse 
texture 
none 


ambient 


A diffuse value indicates 
that diffuse lighting should 
affect this polygon. 


An ambient value indicates 
that ambient lighting should 
affect this polygon 


A diffuse|ambient value in- 
Gicates that both diffuse 
and ambient lighting should 
affect this polygon. 


A texture value indicates 
that this polygon is texture 
mapped. The PCVR Renderer 
does support texture mapped 
objects but has not been 
fully tested at this time. 


A none value indicates that 
no lighting or texture should 
be applied to this polygon. 


The next value is the number 
of vertices that make up this 
polygon. The system can 
currently handle polygons 
made from 2 to 500 vertices. 


The next value is the index 
in the list of vertices of 
the normal vector vertex for 
this polygon. Note that the 
vertices start at 0O. The 
remaining numbers are the 
indices for the vertices 
that make up this polygon. 
The number must be written 
down in clockwise fashion 
when looking at the front of 
the polygon. 


OBJECT PROGRAMMING 


We are not talking about OOP 
here but programming our 
objects. We begin program- 
ming by reading in objects 
then progress to object ma- 
nipulation. 


READING IN OBJECTS 


As described in the previous 
article, the first step in 
using objects is to read them 
into the program. This is 
accomplished using the 
INITIALIZE OBJECT function. 
We first need a variable to 
hold our object. Our objects 
have a structure called 
PObject. To get a variable, 
we define it as: 


PObject *object; 


This variable is set equal to 
the object function above 

object = initialize object 
This function requires sev- 
eral parameters in order to 
read the object. The first 
is the name of the object 
file, the second, third, and 
fourth parameters are the 
translation values. These 


values tell the renderer 
where to place the object in 
the world. An example is 


object=initialize object 
(test.obj,10,10,10); 


If successful, an object 
pointer is returned, other- 
wise, a NULL pointer is 
returned. It is a good habit 
to check the pointer re- 
turned. 


Once the object has been 


read, the system assumes 
that this object is not 
moveable. To give an object 


mobility, we need to attach 
an ATTRIB structure to the 
object. This is accom- 
plished with the function 
NEW ATTRIB. An example is 
new attrib(object) ; 


We can now move our object. 


TRANSLATING OBJECTS 


Translating an object means 
to move the object somewhere 
in the world. We have two 
options in the PCVR Ren- 
derer. We can either move an 
object to an absolute posi- 
tion or we can move the 
object relative to its cur- 
rent position. The two 
functions necessary are 


abs move object ( PObject *, 
long x, long y, long z ); 


rel move object ( PObject *, 
long x, long y, long z ); 


The functions are simple to 
use. To move an object to 
position 100, O, -500, we use 
the absolute function. 
Example: 


abs move object ( 
100, O, -500 ); 


object, 


To move 
URILES, 


an object up 10 
we use the relative 


cube 
a cube 
joe 


# Name 

# Description 
# Author 

# Copyright none 

# Type polygon 

name cube 14 6 8 

000 

0 655360 O 

6553602655360 O 

655260 0-9 

655360 O -655360 

655360 655360 -655360 

0 655360 -655360 

0 0 -655360 

# Start of normal vectors 

0. 0,.65536 

720896 O O 

661293 O -720626 

-65210 O -~-661880 

O 720896 0 

O -65210 -661880 

# End of normal vectors. 
255 255 255 diffuse|ambient 4 

255 255 255 diffuse/ambient 4 

255 255 255 diffuse|/ambient 4 4 
255 255 255 diffuse|jambient 4 11 7 
255 255 255 diffuse/ambient 4 1 
255 255 255 diffusejambient 4 af 


Figure 5 


move function. 


degree. So to rotate an 
Example: 


object about the X axis, 1 
degree from its current 


rel_move_object (object, 0, .ocition, we would: 


10, O ); 


rel rot object ( object, 10. 
ROTATING OBJECTS NPI aawaa 

0, O ); 
In addition to moving ob- 
jects, we can rotate them. 


As in the case of transla- 


The same is true for the 
absolute rotation function. 


tion, we can rotate an object 
either to an absolute posi- 
tion or relative to the 
current position. The func- 
tion available are: 


abs rot object ( PObject *, 
int X, int Y, int Z ); 


rel rot object ( PObject *, 
int x, int Yy int «2.); 


The actual rotation values 
are given in tenths of a 


SOFTWARE 


On the enclosed disk, you 
will find a program called 
pcvrdemo.c. When compiled, 
this program demostrates some 
of the translating and ro- 
tating that can be performed 
using the PCVR Renderer. 
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(This is the second part of 
the article on Visual Per- 
ception of Spatial 
Information.ED. ) 


BINOCULAR SOURCES OF DEPTH 
INFORMATION 


CONVERGENCE 
Convergence is similar to 
accommodation, as it also 


uses muscle tension as a 
source of depth information. 
Also like accommodation, the 
effectiveness of this source 
of information is not agreed 
upon and it may only be 
effective for near objects. 
The two eyes turn toward each 
other as the fixation point 
is moved closer to the viewer. 
For objects further than 6 
meters away, the angle of the 
eyes is essentially zero, or 
parallel, and no convergence 
exists. 


Unlike accommodation, the 
other occulormotor source of 
information, it is possible 
to measure convergence by 
itself, by holding accommo- 
dation constant. This is 
done using a mirror stereo- 
scope virtually identical to 
the one used by Sir Charles 
Wheatstone in his first ste- 
reoscopic experiments over 
150 years ago. A mirror 
stereoscopic is a rather 
simple device, it may con- 
sist of nothing more than two 
mirrors at a right angle. 
This corner of this angle is 
placed directly in front of 
the viewer, pointing at their 
nose. Two pictures are 
placed of the side so that 
they are reflected into the 
viewers eyes. 


Because the viewer focuses 
their eyes on the mirror in 
front of them, accommodation 
remains con 


stant, unless the mirrors 
are moved. Traditionally 
two slightly different pic- 
tures are used to create 
retinal disparity (see be- 
low). To eliminate this 
source of information as 
well, identical pictures are 
used. These identical pic- 
tures are moved laterally to 
change convergence, but keep 
both accommodation and image 
Size identical (Rock, 1984). 
For example, if the two 
pictures are moved laterally 
backward from their original 
position, convergence will 
decrease, with image size 
and accommodation remaining 
constant and no retinal dis- 
parity. Using this design, 
experiments have shown that 
some subjects can use con- 
vergence alone in judging 
distance. 


However Wheatstone in 1852, 
found that apparent size 
decreases as convergence 
increases (as the eyes turn 
toward one another). This 
may lead to errors in dis- 
tance estimates (Adams, 
1955). Emmerts law states 

that the perceived size of an 
object varies directly with 
perceived distance, assum- 
ing a constant visual angle. 
If convergence is giving 
information for distance so 
that the more the eyes turn 
towards one another the closer 
the object will be  per- 
ceived. Because perceived 
distance is smaller, the 
perceived size must also be 
smaller. This has also been 
called stereoscopic constancy 
(Rock, 1984). 


BINOCULAR DISPARITY 

Because human eyes are sepa- 
rated laterally by 65 mm, 
each eye receives a slightly 
different image of the world. 








The difference in these two 
images are usually not readily 
apparent. The differences 
between the two images may be 
more apparent when attention 
is focused on non-fixated 
objects. If the fixation 
point is on a near object, 
the image is on the fovea of 
each eye. While the images 
of the distant, non fixated 
object fall on the nasal 
retina of each eye. These 
are, in effect opposite sides 
of each eye and do not 
correspond, so a double im- 
age exists. This is referred 
to as uncrossed disparity. 
Images for objects closer 
than the fixation point fall 
onthe temporal retina, which 
again do not correspond and 
a double image exists. This 
is referred to as crossed 
disparity. 


These double images have 
been suggested to be a pos- 
sible source of depth infor- 
mation by Hering in the 
1860s. However, the effec- 
tiveness of this information 
has not been examined (Kling 
and Riggs, 1971). 


For a given angle of conver- 
gence, the collection of 
fixation points at which no 
crossed or uncrossed dispar- 
ity occurs is not a flat 
plane, but a curved surface, 
called the horopter. Johannes 
Muller defined the horopter 
geometrically as .a circle 
which passes through the 
fixation point and the cen- 
ter of rotation of the two 
eyes (Kling and Riggs, 1971). 


In humans, and other species 
with forward facing eyes, 
the resulting two, disparate 
images are fused and the 
unique appearance of depth 
and solid shape occurs; ste- 
reopsis. Stereopsis means 
"solid vision". The role of 


stereopsis is thought to be 
one of the reasons that 
Tyrannosaurs Rex was such an 
efficient predator (Bakker, 
1986). It was one of the 
first large predatory dino- 
saurs to have stereoscopic 
vision. 


Stereopsis allows the group- 
ing of objects in the same 
plane even though there may 
be no contour or other group- 
ing feature present. It is 
believed that this may have 
played a role in discrimi- 
nating object recognition in 
camouflage. Since the main 
reason camouflage is effec- 
tive is that it breaks up the 
contour and outline of ob- 
jects, blending them into 
the background, anything 
W ha "5 
eo wu Ta 
ore u’p 
objects 
on rela- 
t lL ¥-¢e 
depth, 
such as 
stereop- 
a 2-2 
would 
help to 
identify 
objects 
= Aa" se 
night 
otiver= 
wise be 
hidden. 


Further 
support 
for this 
is found 
when we 
compare 
the eye ee 
position =} =) 
and per- “"} ue 
centage 
of ste- 
reo 
vision 
in the 


Binocular Fields of View 


360 degree fields of vision 
for predators and prey. In 
the rabbit, a defenseless 
vegetarian, essentially no 
part of its field of vision 
is blind, but only 20 degrees 
of its field of vision is 
binocular. The housecat, a 
well-armed predator, has a 
blind area that is 80 degrees 
of its field of vision, but 
120 degrees are binocular. 


In 1838 Charles Wheatstone 
was able to create retinal 
disparity artificially. He 
invented the mirror stereo- 
scope, which was quickly 
followed by a modification 
by Sir David Brewster who 
used lenses rather than mir- 
rors to present the images. 
Brewsters design was much 


 Saee a 
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more compact and durable 
than Wheatstones and while 
it is still used today, it 
has never regained the popu- 
larity it held in its first 
100 years. 


Wheatstone was able to cre- 
ate retinal disparity arti- 
ficially by presenting 2 
two-dimensional drawings, one 
to each eye. These drawings 
were done by drawing them 
from two different points in 
space. While this is easy to 
do if the points in space 
vary by a great distance, it 
is very difficult to hand 
draw the correct differences 
if the points are separated 
by only 65 mm. Fortunately 
a very precise and inexpen- 
Sive method of creating im- 
ages which differ only in 
their minute spatial dis- 
placement was invented at 
the same time. Pho- 
tography has the 
ability to create 
two images which are 
separated only by 65 
mm and match almost 
exactly what the hu- 
man eye would see. 


Though they are re- 


garded merely as 
quaint, old-fash- 
ioned, toys today, 


the popularity and 
influence that these 
two inventions had 
on society from the 
1860s until -~ the 

1920s has only been 

rivaled by the radio 
and television. 
Stereoviewers al- 
lowed the public to 
visit locations that they 
could never hope to see in 
person. Stereoviewers and 
cards could be rented for an 
evening, much like VCRs and 
tapes today. Stereocards 
were given away as promo- 
tional items, and depicted 
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every facet of interest from 
educational, science, com- 
edy,.golf instruction,;..art 
appreciation and biblical 
tales. 


Two types of stereoscopes 
were invented in the 1850s, 

the mirror stereoscope and 
what came to be known as the 
Holmes stereoviewer. Ina 

mirror stereoscope, as de- 
scribed above, the two dis- 
parate images, placed off to 
the side and in front of the 
viewer, are reflected into 
the viewers eyes. The two 

mirrors at placed at a right 
angle are situated in front 
of the viewer so that the 
corner formed by the mirrors 
points directly at the 
viewers nose. When viewing 

the two images necessary for 
stereo vision, the eyes will 
tend to converge on only one 





Bie 


of the two images. 


In order for each eye to see 
only one of the images, they 
would need to be converged as 
though they were fixated on 
an object in far behind the 
images. In this situation, 





the. .eyes, are not usually 
properly accommodated, so 
the images may be blurry. By 
using the mirrors, accommo- 
dation and convergence are 
correct and stereovision can 
be seen. Though this tech- 
nique does work, it is an 
unwieldy and large device 


Sir David Brewster, who also 
invented the kaleidoscope, 
designed a more compact 
stereoviewer. In this ar- 
rangement, the images are 
place side by side, usually 
glued to one card, directly 
in front of the viewer. Now 
there are two lenses in front 
of the eyes rather than two 
mirrors. The lenses allow 
the accommodation of the 
eyes to relax, the conver- 
gence is virtually zero, 
because the light reflecting 
off the images has_ been 
altered by the 
lenses, accommoda- 
tion relaxes, the 
images are per- 
ceived as being 
soe) further away ‘then 
He Bes they are. (The 
=. monocular depth 
sources of depth 
information in the 
Se ae picture help this 
{ aswell.) Eacheye 
oo «ie cables ote: book 
straight ahead at 
the only the image 
intended for it. 
There is also a 
small barrier/di- 
vider placed be- 
tween the two 


Goa re lenses to further 


discourage the eyes 
from both looking 
at the same view. 


This design was later im- 
proved upon by Supreme Court 
Justice Oliver Wendell Holmes 


into the familiar design 
seen so often at antique 
stores. 


A variety of other tech- 
niques exist to artificially 
produce stereoscopic vision 
but they all have the same 
two basic requirements; at 
least two disparate images 
must be used, and each of the 
images may only be seen by 
the appropriate eye. The 
most widely used alternate 
technique is anaglyph, in 
which the two disparate views 
are printed on top of each 
other. These colors are 
found on opposite sides of 
Newtons color wheel. Inthe 

United States these have 
traditionally been red and 
blue, Europeans use red and 
green. The images are "de- 
coded" and stereoyision is 
perceived when the viewer 
wears the appropriate col- 
ored glasses. With the 
glasses each eye can see only 
of the images (the image 
printed in the same color as 
the lens color). 


While the eyes can tolerate 
large disparities of well 
over 65 mm in the horizontal 
plane, the eyes do not adjust 
well to even small vertical 


disparities. This would be 
expected, as the eyes are 
designed to perceive hori- 
zontal disparities. They 
are located parallel to each 
other inthe horizontal plane. 
In fact, once images are 
fused, even random dot im- 
ages, the disparity can be 
increased over 20 times "nor- 
mal" and the image can still 
be fused correctly (Fox, 
1981). 


Prior to 1970 there was 
little research conducted on 
animals and stereovision. 
To date cats, toads, owls and 
monkeys have demonstrated 
the ability to accomplish 
binocular fusion (Fox, 1981). 
Siamese cats are the excep- 
tion and there is anectdotal 
evidence that Siamese cats 
are more accident prone. 
This may possible be a result 
of their lack of stereovision. 


BINOCULAR RIVALRY 

If the images are not dispar- 
ate, that is they are exactly 
the same, then stereovison 
does not occur. If the 
separate images are not dis- 





parate images of the same 
scene but rather two com- 
pletely different pictures, 
binocular rivalry occurs. 
In binocular rivalry the two 
images are not seen one on 
top of the other as might be 
expected, rather the images 
alternately suppress’) and 
dominate the field of view. 
Thus the left eye image may 
be the only one perceived at 
first, but then it may dis- 
appear and the right eye view 
may be the only image that is 
perceived (Engle, 1958). 
These views will alternate 
Suppression and dominance. 
This is a well known, but 
little understood phenom- 
enon (Blake, 1989). 


The stimulus does not have to 
be presented to both eyes 
Simultaneously in order for 
binocular rivalry to occur 
and the presentation time 
can be of very short duration 
(OShea, Crassini, 1984). 

An exposure time of only 5 
msec is sufficient for bin- 
ocular FYrivalry to “secur, 
even if the presentation to 
each eye is separated by 100 
msec. So long as flicker was 
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discernable, the subjects 
reported no difference be- 
tween this and traditional 
binocular rivalry, where both 
images are presented simul- 
taneously. 


If the images presented are 
both moving at the same 
speed, there is no differ- 
ence in binocular rivalry 
when compared to static im- 
ages (Wade, de-Weert, 
Swanston, 1984). When one 
eye receives a moving pat- 
tern (a grating in which the 
lines appeared to cycle out 
from the center) and the 
other a static grating of the 
same orientation, the moving 
pattern is visible 50% longer. 


Experimenters have found that 
binocular rivalry differs 
from binaural hearing, which 
subjects can use selective 
attention to consciously 
filter out unwanted auditory 
noise from one ear. Subjects 
were asked to detect re- 
peated presentations of a 
target located with a string 
of characters. When this was 
done monocularly, subjects 
had no Girficulty in .com= 
pleting this task. When each 
eye received a different 
string of characters, per- 
formance fell significantly 
(Blake, 1988). 


Binocular rivalry is rarely 
seen outside the lab. How- 
ever, the effect can be used 
for aesthetic purposes in 
stereocards. When markedly 


Left Field 


different 
Concours oc- 
cur for .a 
given spot 
on a 
stereocard, 
banocular 
rivalry will 
ecour - for 
only that 
spot. The 
rest of the 
image will 
be fused 
normaitly 

however, the 3:5: 
small areas }{ | 


which aif- 2 ieee Sea bah ane ae Bane ce Swe ae 


ferwillal- == 
ternatelybe — 
suppressed 
and dominating. This effect 
was used in "tissue" 
stereocards with great suc- 
cess to simulate the candle 
light and glittering of se- 
quins. 


One view would remain "whole", 
the other view would be 
pricked with tiny slits or 
pin holes often at the top of 
candles. The two images 
would be fused, but the area 
of the pin pricks would 
alternately be suppressed 
and dominate so it would 
appear to shimmer, much like 
areal candle. This gave the 
views more sources of infor- 
mation for realism. Similar 
artistic effects are pos- 
sible using binocular ri- 
valry with a stereoscopic 
computer display . 


-> Monocular Object Recognition \ 


Random Dot Stereogram 












Random Dot Stereograms 
Bela Julesz was able 


to 
devise a method for testing 
stereovision which removed 
every source of depth infor- 


mation (except convergence 
some (Bridgeman, 1964) have 
argued, though convergence 
could be held constant by 
using random dot stereograms 
inamirror stereoscope). By 
using random dot stereo- 
grams, every source of depth 
information is removed, there 
is no perspective, no inter- 
position, no shading, no 
texture gradient, just two 
random collection of small 
dots in which no pattern or 
shape may be seen when viewed 
monocularly. (Computer pro- 
grams to generate random do 
stereograms can be easily 
created and displayed with a 
stereoscopic computer 


> Binocular Combination -> Stereopsis 


Right Field -> Monocular Object Recognition 


Flow Chart of Stereopsis Prior to Julesz: 


Left Field \ 
Right Field / 


> Binocular Combination 
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-> Stereopsis 


Based on Ogle (1964) 


-> Object Recognition 


Flow Chart of Stereopsis After Julesz 





display). However when viewed 
stereoscopically, and only 
when viewed stereoscopically, 
simple geometric patterns 
are perceived. These pat- 
terns are very often of 
simple geometric shapes such 
as circles and squares, though 
more complex stimuli, such 
as Necker cubes have been 
presented. When viewed ste- 
reoscopically, random dot 
stereograms, by their na- 
ture, will have these shapes 
either floating in front of 
a background. The shape must 
be at a different plane than 
the background in order for 
it to be perceived. 


The depth of the shapes is a 
direct result of the dispar- 
ity of the two images and the 
manner in which the random 
dot stereograms are created. 
To create a random dot ste- 
reogram a large grid is laid 
out. The spaces in this grid 
are then randomly filled. 
This creates a random dot 
pattern with no discernable 
Organization. This pattern 
will be displayed to one of 
the eyes. This pattern is 
then duplicated and copied 
to the other viewing area for 
display to the other eye. 
From this .,second pattern, 
the particular shape desired 
is copied from the pattern 
and then displaced horizon- 
tally from its original lo- 
cation. Inthis manner, when 
viewed monocularly* there is 
no discernable pattern vis- 
ible. However, when viewed 
stereoscopically the pat- 
tern becomes readily vis- 
ible. 


The image can be thought of 
as a speckled square placed 
floating in front of a speck- 
led background. T= tiie 
scene were viewed monocu- 
larly ina properly illumi- 


nated room and no motion 
parallax was permitted, it 
would be very difficult if 
not impossible to see the 
square. Because there are no 
contours available it could 
be said that the square is in 
essence camouflaged. How- 
ever, when viewed binocu- 
larly, the square is readily 
apparent. 


While this design may at 
first appear to be very 
contrived there are numerous 
examples everyday experi- 
ences which are similar. 
When looking at a tree, the 
pattern of the leaves is 
essentially random and be- 
cause they have varying sizes 
and shapes linear perspec- 
tive and gradient sources of 
depth information are not as 
accessible as they would be 
in a less ambiguous situa- 
tion. Yet the human visual 
system is able to perceived 
depth and recognize which 
cluster of leaves is in the 
foreground and which are in 
the background. 


The first important conclu- 
sion that Julesz drew from 
this discovery was that ob- 
ject recognition did not 
necessarily occur before 
stereopsis. Prior to Juleszs 

Random Dot Stereograms, it 
was believed that monocular 
object recognition had to 


occur before stereopsis 
(Ogle, 1964; Sherrington, 
1906). However, because no 


objects can be recognized 
when viewing random dot ste- 
reograms monocularly, this 
is not true, at least not all 
of the time. 


Julesz termed this phenom- 
enon cyclopean perception 
because the images from the 
two eyes are merged in a 
central location inthe brain 
(like the one-eyed, mythical 


Cyclops) and depth is per- 
ceived (Julesz, 1971). 
Cyclopean vision also in- 
volved the debate between 
local and global stereopsis. 
In local stereopsis, the 
individual features are first 
recognized then, the match- 
ing features are combined. 
In theory, as unlikely as it 
seems, it might be possible 
to match the individual dots 
in a random dot stereogram at 
the local level. However 
Julesz demonstrated that 
fusion was possible even if 
the dots in each field no 
longer looked the same. He 
did this by blurring the 
dots, altering the spatial 
frequency, adding additional 
dots to one field and magni- 
fying the dots in one field 
(Julesz, 1971). In each 
instance, stereopsis is still 
possible, indicating that 
global stereopsis is at work 
rather than local stereop- 
sis. 


The Marr and Poggio (1976, 
1979) neural network is per- 
haps one of the cleanest and 
best working computer models 
of binocular fusion. As it 
is a three dimensional net- 
work of neurons it difficult 
to explain in two dimen- 
sions. If we imagine a very 
Simple network which can 
account for 4 objects in 4 
depth planes at 4 locations 
we have 64 neurons; 4 levels 
each with. d6@ _nenrenss 
Briefly, the network works 
in two steps. First a local 
fusion is done, for each 
object and if it is visible 
by line of sight to each 
neuron. If the object is 
visible to a neuron that the 
neuron is kept alive for the 
second round. 


In the second round the 


neurons inhibit one another, 
if a single, alive neuron is 


Issue #8 March/April, 1993 PC'VR 28 


surrounded by 4 neurons on 
the same level which are not 
active, than that neuron 
will cease to fire. Con= 
versely, if a inactive neu- 
ron is surrounded by live 
neurons, it will begin to 
fire. The neurons above and 
below are then able to exert 
their influence. If this 
process goes through enough 
iterations, a steady state 
will emerge and only those 
neurons who position repre- 
sents the position of the 
objects will continue to 


fire. While no one has 
explicitly said so, this is 
reminiscent of the 


Gestaltists isomorph, as a 
three-dimensional grid pat- 
tern exists which represents 
the spatial location and 
pattern of the objects being 
viewed. 


In recent years modifica- 
tions to the algorithm have 
been made, but the basic 
premise of a neural network 
remains. Pollard, Mayhew 
and Frisby (1984) have de- 
veloped a model which guar- 
antees figural continuity by 
killing off all matches which 
exceed a disparity gradient 
of 1. The disparity gradient 
of two dots is equal to the 
ratio of the distance be- 
tween their disparities and 
the cycloplean separation. 
They chose this number be- 
cause Julesz (1980) has shown 
that humans can not fuse 
images with a disparity gra- 
dient much bigger thanl. By 
doing so, the can more quickly 
and efficiently alienate 
false matches. This was not 
much different from the idea 
behind Mayhew and Frisby 
(1981) earlier model which 
also take figural continuity 
into account but with a less 
elegant equation. 
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VR 


INSIDER 


Brad Burnett 


The object of 
this column 
is to give you 
an inside 


look at 
what’s going 
on in the v.r. 
industry 





; object of this column 
is to give you an inside look 
at what's going on in the 
v.r. industry. As the direc- 
tor of research and develop- 
ment of a new virtual reality 
company. 


I can give you inside cover- 
age of not only what's going 
on but what may soon be going 
on. The name of my company is 
VRontier Worlds and the name 
of our new HMD is Tier 1. 
Tier 1 is an all new head 
mounted display. I began 
developing it in May of 1992 
and just completed it last 
month. We will be in full 
production by March first. 
Tier 1 started out as a home 
brew HMD. 


Tier stands for Totally 
Immersive Exploration Realm. 
The optical system is called 
VRon, which stands for Vir- 
tual Reality Optical Non- 
distortion. The unit has a 
lot of first time features 
for HMDs. For one thing, it 
is very hygienic. Not only is 
the head totally open for air 
flow but the foam mask that 
goes over the eyes to block 
the light is disposable. 


The front part of Tier 1 
Simply detaches from the 
head gear and is ready to 
attach to a boom-type mount. 
I call this feature "con- 
vertible". 


Tier 1 has two high quality 
lcd display screens that 
have a resolution of 479 by 
234. The driver board I 
designed for it has bright, 
tint, and color controls for 
each screen. The optical 
system is a proprietary com- 
pound lens system using cus- 
tom Fresnel technology. The 
field of view is 112 degrees. 


The whole unit only weighs 
3.2 pounds. 


Besides designing v.r. equip- 
ment, I also have a passion 
to write. I just completed an 
epilogue for a new book 
called Adventures In Virtual 
Reality, due out this spring 
by one of my partners and the 
founder of VRontier Worlds, 
Tom Hayward. Last week I 
began discussion with the 
same publisher to write a 
book of my own, which gets a 
little more detailed with 
the theory of head mounts and 
such. 


I want to tell you all why I 
like PCVR so much, and maybe 
tear down a little bit of the 
wall between the industry 
and those who are home enthu- 
Siasts. A year ago, I had 
never before heard of VR. I 
was watching a weekly mini- 
series called "Machines That 
Changed The World" and on one 
of the last episodes, there 
it was. I became obsessed 
from that moment on and went 
crazy trying to get informa- 
tion. I called around and got 
info about a bbs that hada 
v.r. section. That's where I 
got most of the names of 
people to call. I went out 
and bought some Sony t.v.s 
and some LEEP lenses and made 
my first prototype. The main 
problem with it was that 
overall, it stunk! 


Building a home brew HMD can 
be very frustrating. The 
idea of little t.v.s and 
magnifying lenses’' sounds 
Simple until you try it. You 
may soon find that you have 
double vision, can see the 
edges of the screens or 
lenses, and are blind as a 
bat. I still had all of these 
problems even when using the 
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famous LEEP lenses. Not bad 
for a thousand bucks worth of 
optics. I was not a happy 
camper. To further compli- 
cate the matter, I could not 
find anyone who could even 
give me advice. I wondered if 
I was the only one making a 
home brew system. 


I wish I knew about a maga- 
zine like this when I was 
Starting outl At -Vrontier 
Worlds we still do all of our 
v.22°0ff Gt the- pio.” using 
Vream software. This maga- 
zine is the only hands on 
v.r. magazine in the world 
and I believe it is the food 
for<=-thotgnt-: of “the -v.r. 
professionals of tomorrow. I 
want to support it and all of 
you in any way that I can. 


HMD Optics 


Getting optics to work cor- 
rectly with video screens is 
very hard when you do not 
understand optics. Lets spend 
some time going over some of 
the basic principles of the 
type of optical systems needed 
in HMDs. It seems that infor- 
mation in this area is the 
most limited and is’ the 
biggest set back in all of 
the home brew HMDs. 


I learned that you can design 
many different optical sys- 
tems but your choice of video 
displays is very limited. 
The optics need to be devel- 
oped for the displays being 
used. That is one of the 
biggest problems inthe v.r. 
industry. Since optics seem 
so mysterious, a lot of the 
developers chose to buy LEEP 
optics and force the screens 
to try and work with them. To 
get optics to let images 
converge and be immersive 
takes a delicate balance. 
You must first. pick. your 
screen, and design the op- 


28 Issue #8 March/April, 1993 PCVR 


tics back to the eye. 


A field that incorporates 
both electronics and optics 
is called "Photonics". It is 
becoming a new high tech 
field and is very challeng- 
ing even to those who are 
skilled in the art. Before 
you can even think about 
throwing optics on some video 
screens, you must first iden- 
tify what it is that you want 
them to do. Their are several 
basic functions of a virtual 
reality optical system: 


Convergence 
Magnification 
Immersion 
Field of View 
Diffusion 


Convergence is needed when 
the centers of the video 
screens are wider apart than 
the distance between your 
eyes. The average distance 
between an adults eyes is 64 

mm. The screen centers are 
sometimes 75mm apart. If not 
corrected, the eyes would be 
forced to diverge outward. 
This can cause extreme head 
aches. Some have tried to 
correct for this problem by 
angling the screens outward 
from the nose. This causes 
parts of the screens to be 
further from the lenses than 
other parts. Only part of the 
image can then be focused. 
The better way to correct 
this problem is touse prisms. 
The prisms have to be placed 
in a certain way in the 
system for the best advan- 
tages. Prism should be used 
aS sparingly as possible 
because the more the light is 
deviated, the more it is 
degraded. In the future we 
will talk more about this. 


Magnification is needed to 
take the smal! image on the 
video screen and biow it up 
to life size proportions. 


With current display tech- 
nology, the less magnifica- 
tion needed the better. The 
higher power lens you use, 
the larger the dots will 
appear. This is one advan- 
tage of using a larger dis- 
play. The disadvantages are 
of course weight, and that 
the centers will be farther 
apart requiring more prism. 
Magnification is one of the 
hardest figures to nail down 
because if you take a magni- 
fying lens, you will see that 
at different distances from 
the subject, the magnifica- 
tion varies. 


Immersion is a real _ fun 
problem for a sadist. It is 
very unique to virtual real- 
ity so not many people under- 
stand the problem much less 
help with the solution. It 
lends itself to being one of 
the biggest goals of HMDs. 
That is to feel as though you 
are inside the world looking 
out around you instead of 
looking at the world through 
to “holes” like that in a 
viewmaster. To do this, you 
have to realize that your 
vision funnels outward with 
distance from the eye. The 
first lens in the optical 
pack is called the eye lens. 
You must know how far this 
lens will be from the center 
of the eye (the distance from 
the center of the eye to the 
front of the eye, or the 
cornea, is about .5 inches). 
Lets say that the total 
distance from the center of 
the eye to the eye lens is one 
inch. Then the eye lens would 
have to be 2 inches in 
diameter in order for you not 
to see the edges of it. 


Thats all for this time. We 
will pick up where we left 
off next time. Please write 
and send your questions. For 
all home brew hmd builders 
out there; keep the faith. 


Graphics 


Joseph D. Gradecki 


We now 
need a way 
to fill in our 
pictures. .In 
the column, 
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L. the previous Graphics 


columns, we learned to draw 


lines and circles using ad- 
vanced drawing routines. 
These routines can be used to 
create complex pictures, how- 
ever, these pictures will 
still be simple outlines. We 
now need a way to fill in our 
pictures. In the column, we 
will investigate area fill- 
ing. 


BOUNDARY FILLING 


Our first aige~ 


rithm is called 
boundary fill- 
ing and works 
by accepting a 
pixel in our 
ob ject, . plot~ 
ting. .1%, . and 
testing its 
neighbors to de- 
termine if they 
should be filled or not. The 
filling decision is based on 
the boundaries of the object 
to be filled. If any of the 
neighbors of a given pixel 


end loop 





are not the color of the 
boundary of the object, then 
they should be plotted. 
Figure 1 shows a partial 
boundary fill. 


The figure shows an object 
with a boundary color of 
black. If we start filling 
with the pixel at location 


Loop until all filled 
plot pixel in object with fill 
check all neighbors 
if not boundary plot with fiil 


(1,1), the boundary filling 
routine will begin by look- 
ing at the pixel to the north 
of the current pixel. The 
color of this pixel is black, 
which is the boundary color, 
so it is not filled. Next, 
the routine looks at the 
pixel to the east of the 
current pixel. That pixel 
did not have the boundary 
color so it is colored the 
fill color. This continues 
for each of the pixels inside 
of the object. The algorithm 














| 
Bs 


to accomplish this filling 
is shown in figure 2. 


Figure 2 





An appropriate C routine is 
shown in figure 3. 


The exact name for this type 
of filling is called Four- 
Connected Boundary Fill be- 
cause the routine looks at 
just the four neighbors of 
the current pixel and not all 
of the possible neighbors. 
This algorithm works cor- 
rectly for MOST objects but 
not all. Figure 42 shows an 
object that will not be fully 
filled by this algorithm. 


In the object in figure 4, 
the Four Connected algorithm 
would be finished. In order 
to fill the remaining part of 
the object, we would have to 
call the algorithm sepa- 
rately for each of the two 
unfilled pixels. 


Alternatively, we can change 
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the Four-connected algorithm 
into an Eight-Connected al- 
gorithm and solve our prob- 
lems. The code for the Eight 
Connected Boundary Fill al- 
gorithm is shown in figure 5. 


SOFTWARE 


On the enclosed software 
disk are two programs called 
four.c and eight.c. Each of 
these program demostrates 
the appropriate boundary fill 
algorthm discussed in the 
column. 


CONCLUSION 


These algorithms suffer from 
two problems. The first is 
that the boundary color and 
the fill color can not be the 
same. This means that all of 
our objects will have bor- 
ders to them. The second 
problem is speed. Recursion 
is very expensive and slow. 
In addition, if we tried to 
boundary fill a large ob- 
ject, we could potentially 
run out of stack space for 


the recursions. 


NEXT ISSUE 


In the next Graphics column, 
we will tackle the second 
problem and look at a faster 
area filling algorithm. 
Future columns will deal 


with the multi-color issue. 
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void fitl_ ic (“int x, 


( 
( 
( 
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( 
( 
( 
( 
( 
( 
( 
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void fill it ( int x, int y, int fill, int boundary ) 


int current color; 
current color := get color ( x, y )? 
if (({ current _color != fill ) && (current coior 


putpixel (_x, y, fill ); 

x, y-1, fill, boundary ) 
x, yi, Till, Boundary } 
R=1l, Vy IThLil,; BoUndGery } 
xt+l, y, fill, boundary } 






Figure 3 








ant , ast fill, 


int current color; 


Get CoLlcr ( Bas ¥o de 


if (( current_color != fill ) && (current_color 


putpixel ( x, y, fill ); 


x, yrl, £111, boundary ); 
x, vi, filig*boundary };; 
x-1, y, fill, boundary. ),; 
x+1, y, £111, boundary ); 
Xl, yol,| fill, boundary: 32 
wel, yi, Fill, boundary }; 
xt+1,.. ¥~1, | filby  Deningary: 3 
e+l,.yri, fill, boundary ); 






Figure 5 
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Pal column in the Virtual 
Racquetball series, we will 
investigate addition colli- 
sion detection with two mov- 
ing objects and adding 3D 
support. 


COLLISION DETECTION 


In the previous column, we 
discussed collision detec- 
tion between the stationary 
racquet and the moving vir- 
tual hand. We began by 
calculating the position of 
the center of the racquet 
using the get object bounds 
function. Since the racquet 
was not moving, we only had 
to get the position once. We 
then used the pretest sphere 
function to determine if a 
collision has occurred be- 
tween the handle and the palm 
object. 


Now we want to determine if 
a collision has occurred 
between the ball and the 
center of the racquet. The 
code that performs this task 
is shown in figure l. 


if (!NO RACQUET) 
{ 


We begin by making sure that 
we have the racquet in our 
hand. If we dont, then 
there is no reason to test 
for a collision between the 
racquet and the ball. If we 
do have the racquet, we get 
the center coordinates of 
the ball at this particular 


moment. These coordinates 
are used along with the 
racquet object in the 


sphere pretest function to 
determine the distance be- 
tween the two objects. This 
distance is output on the 
screen to help the _ user 
locate the ball. 


The test for a collision 
comes with the statement 
if(dist<300). If we are 
within a few units of the 
ball, then we say acollision 
has occurred. If the dis- 
tance is greater than 300, 
then we try again for a 
collision on the next itera- 
tion. Notice that we must 
always get new coordinates 
for the center of the ball 
when we try to determine if 


rad=get object bounds(ball object,&x,&y,&z); 
dist = sphere pretest (racquet object,x,y,2); 

sprintf(buf, Ball dist: %1aY, dist ); 
Prprimc 2, 3, 15, wut }? 


if (dist<300) 
: 


if ( ine. val 2 < 0.) 
inc_val_z = BALL _SPEED*5; 


else 


inc_val z = -BALL SPEED*5; 
Zz position += inc val z; 


} 


Figure 1 
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a collision has occurred. If 
a collision has taken place, 
we send the ball in the 
Opposite Z direction at a 
much higher rate than nor- 
mal. Thus, if the ball is 
heading toward the back wall 
and there is a collision with 
the racquet, the ball will 
change directions and start 
moving towards the front 
wall. The reverse is true 
for a ball moving toward the 
front wall. 


In real life, gravity plays 
a big part in the speed of an 
object once set ina particu- 
lar direction. Therefore, 


our ball must begin to slow 
down as it moves in the 
Opposite direction. This is 
performed by the ball move- 
ment routine move ball. The 
code is: 


if (inc _val_z>BALL_ SPEED) 
inc val z -= 1; 

if (inc_val_z<-BALL_ SPEED) 
inc val _z += 1; 


The normal BALL SPEED value 
is .20..,We, set, She oine-.vel 
variable to a value of 50 
when the ball is hit. As the 
ball moves, it will be 
decremented in speed by 1 
unit per each iteration un- 


if(stereo type != MONOSCOPIC) 


{ 


init switch driver(swdname) ; 


if(sl_ left<0) 


{ 
sl left = default view.left; 
sl_ right = default view.right; 
Sl_top = default view.top; 
Sl_ bottom = default view.bottom; 
} 


til the speed .s equal to 
BALL SPEED. This is a crude 
Simulation of the effects of 
gravity on the ball but it 
does show the desired ef- 
fect. 


SEGA 3D SUPPORT 


The last thing to look at for 
the game is adding SEGA 3D 
glasses support. Just as in 
the case of the 

Powerglove, most of the work 


for the SEGA glasses is 
performed behind the scenes. 
However, some initializa- 


tion work needs to be done. 
The code in figure 2 should 


compute stereo data(&default stereo, Wy sl xflip, sl xoff, 
65536.0*sl xrot, 
sl lett, sl: top; sl_right, #81 bottom); 


if(sr_left<0) 


{ 
sx_left = default view. left; 
sr_ right = default view.right; 
Sr_top = default view.top; 
Ssr_ bottom = default view.bottom; 
} 


compute stereo data(&default_ stereo, 1, sr xflip, 
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sr xoff, 


65536.0*sr xrot, 
sr_left, sr_top, sr_right, sr_ bottom); 


Figure 2 





be added after the 


initialize screen factors 
(current view); 


statement in the MAIN func- 
tion. 


This code initializes the 
internal SEGA glasses driver 
and sets up the stereo views 
according to the global vari- 
ables defined in the pro- 
gram. The variables sl left 
and sl] right are set to -1 if 
the appropriate views need 
to be initialized. The views 
are setup using the current 
stereo values and the cur- 
rent screen defaults. 


After this code is added to 
the program, it is ready for 
sega support. The next step 
is to change the _ file 
REND386.CFG to initiate the 
SEGA glasses when the pro- 
gram is executed. This file 
should look like: 


switchdev sega 


segaport aac 8.5 2.0 O 
stereoset 1000 250 320 50 
1000000 1.0 

stereotype SWITCH 


The first line tells the 
program that we are using the 
Switch device sega as the 
controller. The second line 
tells the program that the 
sega glasses are at COM] and 
which bitmasks to use when 
switching the eyes.» Check 
the original REND386.CFG file 
for more explanation. The 
third line sets up the stereo 
values to use for the pro- 
gram. Of important signifi- 
cance is the next to the last 
value. In typical REND386 
programs, most of the ob- 
jects are fairly close to the 
viewer and our eyes can fuse 
the images correctly. Inthe 
case of the racquetball game, 
we display objects farther 


out into the scene. If the 
value in this line is set to 
1000, some people will see 
two images and others just 
one of distant objects. By 
setting this value to some- 
thing like 100000, we do not 
render the different images 
quite so far apart allowing 
more people to see three- 
dimensional images. The 
last line in this file tells 
the system that we are no 
longer a MONOSCOPIC system 
but now the SWITCHED system. 
This new category triggers 
several internal functions 
to display the different 
images to the screen. 


The 3D effect is quite good 
in most cases but it can be 
hard to actually hit the 
ball. This is a result of 
limited vision in the game 
from using the 3D glasses. 


CONCLUSION 


Over the last four issues, we 
have documented the con- 
struction of the very first 
application using REND386, 
the Mattel Powerglove, and 
the SEGA 3D glasses. Our 
next project in the Working 
With REND386 column will be 
the development of the PCVRJET 
and Virtual Menus. 
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T ne enclosed disk includes the following programs: 


In the GRAPHICS directory: 


FOUR.c and FOUR.exe - This program demonstrates the four-connected fill algorithm 
discussed in the GRAPHICS column. It can be compiled using the BORLAND/TURBO C 


environment. 


EIGHT.c and EIGHT.exe - This program demonstrates the eight-connected sage a 
algorithm discuess in the GRAPHICS column. It can be compiled using the BORLAND/TURBO 
C environment. 


In the REND386 directory: 


RB.c - This is the final racquetball program. It can be compiled using the project 
file found in Issues 5,6, and 7 of PCVR. 


REND386.cfg - This is the configuration file used with the RB.c program. 


In the PCVRREND directory: 


PCVRDEMO.c and PCVRDEMO.exe - This program demonstrates some of the capabilities 
of the PCVR Renderer. It can be compiled using the MAKE facility of BORLAND/TURBO C and 
the makefile called 'makepdem' and the link file 'linkpdem'. 


PCVRSKEL.c - This program is a skeleton program for the PCVR Renderer. It simply 


presents a single object to the screen. The program is exited using the 'q' key. It 
can be compiled using the MAKE facility of BORLAND/TURBO C and the makefile called 


'makepcvr' and the link file ‘'linkpcvr'. 


*.obj - The remainder of the object files in the directory are used by the PCVRDEMO 
and PCVRSKEL programs. 


cube.obt - This is a PCVR Renderer object used by both PCVRDEMO and PCVRSKEL. 


readme - This has information about the make and link files. 
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My 
Virtual 


Playground 


| er the technology of Virtual Reality seems to expand and mature. I am amazed 
at the breadth of people that have an interest in it. Just the other day, we received 
a call from a farmer who was interested in using VR to help him in the field. I am not 
at liberty to divulge his use but it was a very feasible and good idea. 


We are currently, as I write this, three weeks from VR Systems 93 in New York, and two 
and one half months from VR 93 in San Jose. I may see some of you at VR Systems 93, 
however I will be there not as a representative of PCVR but ina different capacity. I 
sure hope to see some good applications and not just the same ol worlds. 


I would like to present a personal challenge to everyone in the VR community and those 
Simply interested in the technology. We need applications. I may be beating a dead horse 
but its the truth. 


We will do our part at VR 93 in San Jose to have a system that presents the user with 
a MENU of applications in which they can explore. We will use the PCVR Renderer and REND386 
to create the applications. It is our intent to show what can be accomplished on the 
low end of VR using inexpensive equipment. We will not use the Powerglove because of 
the sound problem at conventions so instead we will use the Global 3D Controller described 
in the What's New section of this issue of PCVR. We are really excited about the 
convention. If you are in San Jose, California around May 21-23, stop by the Fairmont 
Hotel and check out the exhibit. 


If you have a possible application that you would like to build and program, not just 
a world, but a real application, we would be interested in using it. What will you get 
for your trouble? A great amount of exposure. We will mention you in the virtual menu 
system and will provide you with any contacts that ask about your application. 


In order to participate, contact us with your idea so that we don't get any duplicate 
applications. Together, we will determine the specifics of what is necessary for the 
menu system. We would like to have somewhere between twenty and thirty applications that 
the visitors to the conference can experience. Some ideas might be a simple childrens 
addition game, a walk through a museum, or a program that visually helps a person 
understand the growing federal deficit and ways we can 'contribute' to its reduction. 
The deadline for the challenge is April 30th. Any takers!? 


Joseph D. Gradecki 
Publisher, PCVR 
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